Communication device, communication method and recording medium

ABSTRACT

According to an aspect of the present invention, a device for communication according to a specific communication protocol includes a processor for generating a connection request frame for requesting a connection to other device based on the communication protocol. The connection request frame includes a predetermined field. The processor initiates data communication at predetermined timing in a given time interval in the case of setting the predetermined field of the connection request frame to a predetermined value and receiving a connection assignment frame for accepting the connection request from the other device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority under35 USC 119 of Japanese Patent Application No. 2016-008434 filed on Jan.20, 2016, the entire disclosure of which is incorporated herein byreference in its entirety for all purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a communication device, a communicationmethod, and a computer readable recording medium for recording a programfor executing the communication method.

2. Description of the Related Art

Conventionally, many research studies have been done on application ofthe information communication technology to fields where devicesdisposed in close vicinity to a human body are used, such as health andmedical care. The institute of electrical and electronics engineers(IEEE) 802 LAN/MAN Standards Committee proposed the 802.15.6 standardprotocol for the purpose of low-power local area wireless communicationfor Body Area Network (BAN) applications.

The IEEE 802.15.6 protocol defines a physical (PHY) layer and a mediumaccess control (MAC) sublayer for the wireless BAN (also referred to asWBAN) operating in-body, on-body, or off-body. Here, the “body” is notlimited to the human body and includes bodies of animals and organismshaving propagation environment similar to the human body.

According to the IEEE 802.15.6 protocol, a device belonging to a BANserves as a hub or a node. One hub and one or more nodes form anindependent network. For example, the node is a small sensor such as apulsimeter, an electrocardiograph, or an acceleration sensor which isattached to a user's body to monitor the user's physical condition andthe hub is a terminal for collecting data from each sensor. Generally, aterminal serving as the hub has larger battery capacity than a sensorserving as the node because the terminal serving as the hub is notnecessarily required to be directly attached to the user's body andshould collect data from a plurality of sensors connected thereto. Onthe contrary, since the node is often powered by a small battery, it isimportant to reduce power consumed for communication in order toincrease device operating time of the node.

Generally, a node waits for receiving a poll or data from a hub andperforms transmission of data after receiving the poll or data from thehub in a given allocation slot in a bilink for bidirectionalcommunication, as disclosed in PCT Publication No. WO2013/014757published on Jan. 31, 2013.

SUMMARY OF THE INVENTION

According to the conventional technology as described above, the nodeshould maintain a receivable state until it receives the poll or datafrom the hub. For an unscheduled allocation in which an allocation slotcan be shifted in time, the receipt standby time may be too long. Thisreceipt standby time results in increase of power consumption of thenode.

An object of the present invention is to provide a communication methodfor reducing power consumption of a terminal by reducing the standbytime for data communication, a device for executing the communicationmethod, and a computer readable recording medium for recording a programfor executing the communication method.

According to one aspect of the invention, a device for communicationaccording to a specific communication protocol includes a processor forgenerating a connection request frame for requesting a connection toother device based on the communication protocol. The connection requestframe includes a predetermined field. The processor initiates datacommunication at predetermined timing in a time interval given forcommunication with the other device in the case of setting thepredetermined field of the connection request frame to a predeterminedvalue and receiving a connection assignment frame for accepting theconnection request from the other device.

According to one aspect of the invention, a device for communicationaccording to a specific communication protocol includes a processor forgenerating a connection assignment frame for accepting a connectionrequest of other device based on the communication protocol. Theconnection assignment frame includes a predetermined field. Theprocessor does not transmit any data frame until the other deviceinitiates data communication in the case of setting the predeterminedfield of the connection assignment frame to a predetermined value.

According to embodiments of the present invention, it is possible toreduce power consumption of a terminal for communication.

The above and further objects and novel features of the presentinvention will more fully appear from the following detailed descriptionwhen the same is read in conjunction with the accompanying drawings. Itis to be expressly understood, however, that the drawings are for thepurpose of illustration only and are not intended as a definition of thelimits of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will more sufficiently be understood by thefollowing detailed description and the accompanying drawings, which areintended exclusively for explanation and do not limit the scope of thepresent invention.

Here:

FIG. 1 is a diagram showing a topology of a body area network (BAN).

FIG. 2 is a block diagram showing a communication system according to anembodiment of the invention.

FIG. 3 is a diagram showing a physical (PHY) layer and a medium accesscontrol (MAC) sublayer in a hub or a node. FIG. 4 is a diagram showing atime reference base of the BAN.

FIG. 5 is a layout of access phases in a beacon period for beacon mode.

FIG. 6 shows (A) a format of a MAC frame, (B) a format of MAC header,(C) a format of a Frame Control field, and (D) a format of a MAC framebody.

FIG. 7 shows a format of a frame payload of a Connection Request frame.

FIG. 8 shows (A) a format of an Uplink Request information element (IE),a Downlink Request IE, a Bilink Request IE, or a Type-I UnscheduledBilink Request IE of a Connection Request frame, and (B) a format of anAllocation Request field of the IE, according to an embodiment of theinvention.

FIG. 9 shows (A) a format of a Type-II Unscheduled Bilink Request IE ofa Connection Request frame, and (B) a format of a Type-II UnscheduledAllocation Request field of the IE, according to an embodiment of theinvention.

FIG. 10 shows a format of a frame payload of a Connection Assignmentframe.

FIG. 11 shows (A) a format of an Uplink Assignment IE, a DownlinkAssignment IE, a Bilink Assignment IE, or a Type-I Unscheduled BilinkAssignment IE of a Connection Assignment frame, and (B) a format of anAllocation Assignment field of the IE, according to an embodiment of theinvention.

FIG. 12 shows (A) a format of a Type-II Unscheduled Bilink Assignment IEof a Connection Assignment frame, and (B) a format of a Type-IIUnscheduled Allocation Assignment field of the IE, according to anembodiment of the invention.

FIG. 13 is a signal flow diagram showing a process of conventionalType-I unscheduled bilink communication.

FIG. 14 is a signal flow diagram showing a process of Type-I unscheduledbilink communication according to an embodiment of the invention.

FIG. 15 is a flow chart showing operations of an algorithm performed bya node according to an embodiment of the invention.

FIG. 16 is a flow chart showing operations of an algorithm performed bya hub according to an embodiment of the invention.

FIG. 17 is a flow chart showing operations of an algorithm performed bya node according to another embodiment of the invention.

FIG. 18 is a flow chart showing operations of an algorithm performed bya hub according to another embodiment of the invention.

FIG. 19 is a flow chart showing operations of an algorithm performed bya node according to another embodiment of the invention.

FIG. 20 is a flow chart showing operations of an algorithm performed bya hub according to another embodiment of the invention.

FIG. 21 shows (A) an exterior view of an electronic timepiece typedevice according to an embodiment of the invention, and (B) a blockdiagram showing a hardware configuration of the electronic timepiecetype device according to the embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the present specification, the invention will be mainly described inconnection with embodiments in which it has been applied to the BAN butits application field is not limited to the BAN. For example, theinvention can be applied to different wireless communicationtechnologies such as Bluetooth®, Wi-Fi®, and Wi-Fi Direct®.

Hereinafter, embodiments of the present invention will be described withreference to the accompanying drawings. The scope of the invention isnot intended to be limited to the illustrated examples.

FIG. 1 is a diagram showing a topology of the body area network (BAN). ABAN 10 includes a device, which plays the role of a hub H, and one ormore devices each of which plays the role of a node N. There is to beone and only one hub in a BAN, whereas the number of nodes in the BAN isto range from zero to the maximum number of nodes connectable to the hub(mMaxBANSize). In the example shown in FIG. 1, four nodes N1 to N4belong to the BAN 10, but the number of nodes is not limited to thisexample. The hub H is a mobile terminal such as a smart phone or apersonal digital assistant (PDA), or an electronic timepiece providedwith a communication function, for example. The node N is a bio-signalmeasuring device, a bio-signal monitoring device or a sensor formeasuring/receiving bio-signals and transmitting to the hub H, or anelectronic timepiece including one or more of them, for example.

FIG. 2 is a block diagram showing a communication system according to anembodiment of the invention. In the present embodiment, a communicationsystem 20 includes a device 200 serving as a hub and a device 300serving as a node. Although the example of FIG. 2 depicts one nodecommunicating with the hub, the number of node(s) connectable to the hubis not limited to this example. The device 200 communicates with one ormore nodes and controls them. The device 300 is a low-power wirelessnode operating in, on, or around the body (not limited to the humanbody) for one or more applications such as a medical device, anelectronic appliance, or a personal amusement device.

The device 200 includes a wireless communicator 210, a processor 220,and a memory 230. The processor 220 processes messages exchanged via anantenna 212 and the wireless communicator (or, a transceiver) 210 and/orvia a wireline connected to the internet or a different body areanetwork (not shown in the drawings). The antenna 212 transmits andreceives electromagnetic waves of a frequency corresponding to awireless communication method adopted by the processor 220. The wirelesscommunicator 210 includes a circuit for transforming an electric signalinput from the processor 220 into an electromagnetic wave ortransforming a received electromagnetic wave into an electric signal tooutput it to the processor 220. These electric signals are transmittedand received on a frame-by-frame basis. In the present embodiment, theprocessor 220 generates a frame to be transmitted to other device, forexample, the device 300, according to the BAN protocol, and processes(for example, decodes) a frame received from other device, for example,the device 300, according to the BAN protocol. The processor 220 mayinclude software, firmware, hardware, or a combination thereof.

The memory 230 can be used to store frame structure information, mediumaccess control information, power management information, or the like,as well as data of frames transmitted or received (hereinafter, referredto as “frame data”). In particular, information on history ofconnections between the device 200 and other devices (hereinafter,referred to as “history information”) can be stored in the memory 230.The history information may include information recorded in a MAC framereceived from other device. The information recorded in the MAC frameincludes MAC Capability and PHY Capability of the other device, forexample. Further, the memory 230 may also be used to store computerprogram instructions, software and/or firmware executed by the processor220. The memory 230 may be any storage device such as a RAM (RandomAccess Memory), a ROM (Read Only Memory), a flash memory, or a diskdrive integrated into or removable from the communication device 200.Alternatively, the memory 230 may be any storage device integrated intoor removable from the processor 220.

The device 300 includes a wireless communicator 310, a processor 320,and a memory 330. The processor 320 processes messages exchanged via anantenna 312 and the wireless communicator (or, a transceiver) 310. Theantenna 312 transmits and receives electromagnetic waves of a frequencycorresponding to a wireless communication method adopted by theprocessor 320. The wireless communicator 310 includes a circuit fortransforming an electric signal input from the processor 320 into anelectromagnetic wave or transforming a received electromagnetic waveinto an electric signal to output it to the processor 320. In thepresent embodiment, the processor 320 generates a frame to betransmitted to other device, for example, the device 200, according tothe BAN protocol, and processes a frame received from other device, forexample, the device 200, according to the BAN protocol. The processor320 may include software, firmware, hardware, or a combination thereof.

The memory 330 can be used to store the frame structure information, themedium access control information, the power management information, orthe like, as well as the frame data transmitted or received. Inparticular, information recorded in a MAC frame received from otherdevice, for example, the device 200 can be stored in the memory 330. Theinformation recorded in the MAC frame includes MAC Capability of theother device, for example. Further, the memory 330 may also be used tostore computer program instructions, software and/or firmware executedby the processor 320. The memory 330 may be any storage device such as aRAM (Random Access Memory), a ROM (Read Only Memory), a flash memory, ora disk drive integrated into or removable from the communication device300. Alternatively, the memory 330 may be any storage device integratedinto or removable from the processor 320.

The device 200 or 300 can be connected to a sensor (not shown in thedrawings) used to monitor data from the body such as body temperature,respiration, heart rate, or blood sugar, or a device (not shown in thedrawings) for providing a function of controlling a pace maker, arespirator, an insulin pump, or the like, for example.

The network 10 shown in FIG. 1 and the system 20 shown in FIG. 2 aremerely examples and do not limit the scope of systems or devices capableof implementing frame generating methods or frame processing methodsdescribed herein. Any device for performing communication according tothe present invention falls within the scope of the invention.

The hub 200 or the node 300 is internally partitioned into a physical(PHY) layer and a medium access control (MAC) sublayer. FIG. 3 is adiagram showing the PHY layer and the MAC sublayer according to theISO/OSI-IEEE 802 reference model. Direct communications between the nodeand the hub are to transpire at the PHY layer and the MAC sublayer. Inthe present embodiment, the PHY layer and the MAC sublayer of the nodeor the hub are to use only one operating channel at any given time.However, the present invention is not limited thereto.

Within the node or the hub, the MAC provides its service to the MACclient (higher layer) through the MAC service access point (SAP) locatedimmediately above the MAC sublayer, while the PHY provides its serviceto the MAC through the PHY SAP located between them. On transmission,the MAC client passes MAC service data units (MSDUs) to the MAC sublayervia the MAC SAP, and the MAC sublayer passes MAC frames (also known asMAC protocol data units or MPDUs) to the PHY layer via the PHY SAP. Onreception, the PHY layer passes MAC frames to the MAC sublayer via thePHY SAP, and the MAC sublayer passes MSDUs to the MAC client via the MACSAP.

In the following, the medium access will be described referring to FIGS.4 and 5. All nodes and hubs are to establish a time reference base, asshown in FIG. 4, if their medium access is to be scheduled in time. Toprovide or support time referenced allocations in its BAN, the hub shallestablish a time base, which divides the time axis into beacon periods(superframes) regardless of whether it is to transmit beacons. Eachbeacon period is composed of allocation slots of equal length andnumbered from 0, 1, . . . , s, where s≦255. In such cases, the hub shalltransmit a beacon in each beacon period (superframe), except in inactivesuperframes, or shall not transmit a beacon in any superframe. A beaconis a frame transmitted by the hub in order to let nodes know existenceof the network of the hub and make the nodes participate in the network.Further, the beacon is transmitted by the hub to facilitate networkmanagement, such as the coordination of medium access and powermanagement of the nodes in the body area network (BAN) of the hub, andto facilitate clock synchronization therein.

According to the IEEE 802.15.6 protocol, the hub shall operate in one ofthe following three access modes.

(1) Beacon mode with beacon periods (superframes): The hub shalltransmit a beacon in each beacon period except in inactive superframesto enable time referenced allocations.

(2) Non-beacon mode with superframes: The hub shall transmit no beaconsalthough access to the medium involves time referencing and superframesand allocation slots are established. In this mode, the hub may haveonly a managed access phase (MAP) in any superframe.

(3) Non-beacon mode without superframes: Access to the medium involvesno time referencing and the hub shall transmit no beacons.

In a network comprising a hub and one or more nodes, various accessmethods may be used to obtain an allocation interval for initiatingframe transactions between the nodes and the hub. The access methods aredivided into two main categories: a scheduled access and an unscheduledaccess. The scheduled access is based on advance reservation andcommitted scheduling, whereby a node and a hub obtain scheduledreoccurring time intervals for initiating frame transactions. Theunscheduled access is a combination of best-effort scheduled access andpolling access. In an unscheduled access, the hub grants to the node orto itself non-reoccurring time intervals for initiating frametransactions in an uplink, downlink, or both (called bilink).

A frame transaction comprises a management or data type frame. In anuplink, the node sends management and/or data type frames to the hub,but not the other way around. In a downlink, the hub sends managementand/or data type frames to the node, but not the other way around. In abilink, the node sends management and/or data type frames to the hub,and/or vice versa.

A hub and a node that support unscheduled access may employ unscheduledaccess to initiate frame transactions in a downlink and/or uplink on abest-effort basis. Support for unscheduled access may be indicated in anexchanged MAC Capability field. Connection Request and ConnectionAssignment frames may be used to provide advance reservations andtentative allocation interval assignments. To support unscheduled accessin beacon or non-beacon mode with superframes, a node shall be alwaysactive during time intervals wherein polls and posts are allowed to besent.

FIG. 5 is a layout of access phases in a beacon period for beacon mode.In beacon mode, the hub shall organize access phases in each activebeacon period (superframe) as shown in FIG. 5. In FIG. 5, B stands forbeacon (B). In an active superframe (beacon period), the hub shalltransmit a beacon and may provide access phases. Access phases are usedto exchange management, control, and data type frames. In an inactivesuperframe (beacon period), the hub shall not transmit any beacon andshall not provide any access phases.

The hub shall place exclusive access phase 1 (EAP1), random access phase1 (RAP1), managed access phase (MAP), exclusive access phase 2 (EAP2),random access phase 2 (RAP2), another managed access phase (MAP), andcontention access phase (CAP) in the order shown in FIG. 5. To provide anon-zero length CAP, the hub shall transmit a preceding B2 frame. Thehub shall not transmit a B2 frame if the CAP that follows has a zerolength.

In order for a hub and a node to communicate data, the node transmits aConnection Request frame to the hub to require allocation slots for thecommunication. In the case that the hub accepts a connection of thenode, one or more frame transactions are performed between the hub andthe node in allocation slots specified in a Connection Assignment framefrom the hub. In specific, in bilink communication, the node waits forreceipt of a transmission command (or, a poll) or a data frame(hereinafter, collectively referred to as a “transmission allowancenotice”) from the hub in a given allocation slot, and, after receipt ofthe transmission allowance notice, performs transmission of a dataframe. For the unscheduled allocation in which an allocation slot can beshifted in time, the receipt standby time of the node may be too longresulting in increase of power consumption of the node.

In the following, a MAC frame structure of each of a Connection Requestframe and a Connection Assignment frame used for BAN communication willbe described. The Connection Request frame is a frame transmitted by thenode to request creation or modification of a connection with the hub.The Connection Assignment frame is a frame transmitted by the hub torespond to a connection request or to initiate or change a connectionassignment. A format of a MAC frame according to the present embodimentis shown in (A) of FIG. 6. The MAC frame includes a fixed-length MACheader, a variable-length MAC frame body, and a fixed length Frame CheckSequence (FCS) field. The Frame Check Sequence (FCS) field is the footerof the MAC frame. The fields contained in the MAC frame will be definedin the following. Each of the figures explained below depicts the fieldscontained in the MAC frame from left to right in the transmit order,with fields that are optional or selectively absent drawn in dashes.Also indicated is the number of octets contained in each field alongwith the corresponding octet transmit order, on top of the field.Reserved fields are set to zero on transmission and ignored onreception.

A format of the MAC header according to the present embodiment is shownin (B) of FIG. 6. The MAC header includes Frame Control, Recipient ID,Sender ID, and BAN ID fields. The Recipient ID field is set to theabbreviated address (i.e., NID (Node Identifier) or HID (HubIdentifier)) of the recipient of the current frame. The Sender ID fieldis set to the abbreviated address (i.e., NID or HID) of the sender ofthe current frame. The BAN ID field is set to the abbreviated address ofthe BAN in which the current frame is transferred.

A format of the Frame Control according to the present embodiment isshown in (C) of FIG. 6. Each field of the Frame Control is defined inSection 5.2.1.1 of IEEE Std 802.15.6-2012. Frame Subtype and Frame Typefields of the Frame Control are set to indicate the type of the currentframe according to Table 1 below.

TABLE 1 Frame Type and Frame Subtype field encoding Frame Type valueFrame Frame Subtype value Frame b5b4 Type name b3b2b1b0 Subtype name 00Management 0000 Beacon 00 Management 0001 Reserved 00 Management 0010Security Association 00 Management 0011 Security Disassociation 00Management 0100 PTK 00 Management 0101 GTK 00 Management 0110-0111Reserved 00 Management 1000 Connection Request 00 Management 1001Connection Assignment 00 Management 1010 Disconnection 00 Management1011-1110 Reserved 00 Management 1111 Command 01 Control 0000 I-Ack 01Control 0001 B-Ack 01 Control 0010-0011 Reserved 01 Control 0100 I-Ack +Poll 01 Control 0101 B-Ack + Poll 01 Control 0110 Poll 01 Control 0111T-Poll 01 Control 1000-1101 Reserved 01 Control 1110 Wakeup 01 Control1111 B2 10 Data 0000 User Priority 0 or Allocation Mapped Data Subtype10 Data 0001 User Priority 1 or Allocation Mapped Data Subtype 10 Data0010 User Priority 2 or Allocation Mapped Data Subtype 10 Data 0011 UserPriority 3 or Allocation Mapped Data Subtype 10 Data 0100 User Priority4 or Allocation Mapped Data Subtype 10 Data 0101 User Priority 5 orAllocation Mapped Data Subtype 10 Data 0110 User Priority 6 orAllocation Mapped Data Subtype 10 Data 0111 Emergency 10 Data 1000-1111Allocation Mapped Data Subtype 11 Reserved 0000-1111 Reserved

As shown in Table 1, the value of the Frame Type indicates the type ofthe current frame. More specifically, in the case that the value of theFrame Type is 00, the current frame is a Management frame. In the casethat the value of the Frame Type is 01, the current frame is a Controlframe. In the case that the value of the Frame Type is 10, the currentframe is a Data frame. In the case that the value of the Frame Type is11, the current frame is a Reserved frame. The value of the FrameSubtype is set according to the subtype of the current frame. Thus, thecombination of the Frame Type value and the Frame Subtype valueindicates the kind of the current frame. For example, in the case thatthe Frame Type value is 00 and the Frame Subtype value is 0000, thecurrent frame is a beacon frame. In the case that the Frame Type valueis 00 and the Frame Subtype value is 1000, the current frame is aConnection Request frame. In the case that the Frame Type value is 00and the Frame Subtype value is 1001, the current frame is a ConnectionAssignment frame. In the case that the Frame Type value is 01 and theFrame Subtype value is 0000, the current frame is an I-Ack frame.

A format of the MAC frame body according to the present embodiment isshown in (D) of FIG. 6. Low-Order Security Sequence Number and MessageIntegrity Code (MIC) fields are not present in unsecured frames, asindicated by the Security Level field of the Frame Control of the MACheader of the current frame. Frame Payload is a sequence of fields to becommunicated to the recipient(s). An I-Ack frame transmitted by a nodeto a hub contains no Frame Payload. An I-Ack frame transmitted by a hubto a node selectively contains a Frame Payload.

A Connection Request frame according to the present embodiment includesa frame payload formatted as shown in FIG. 7. The Recipient Addressfield is set to the EUI-48 (EUI: Extended Unique Identifier) of therecipient of the current frame, or is set to zero if such an EUI-48 isyet unknown. The Sender Address field is set to the EUI-48 of the senderof the current frame. Each of other fields of the frame payload of theConnection Request frame is defined in Section 5.3.6 of IEEE Std802.15.6-2012.

The Connection Request frame contains information elements (IEs), asshown in FIG. 7. Each information element contains an element ID fieldwhich is set to the value that identifies the information element, alength field, and an information field (see (A) of FIG. 8 and (A) ofFIG. 9). The length field is set to the length, in octets, of theinformation field.

The Uplink Request IE of the Connection Request frame is formatted asshown in (A) of FIG. 8 (where N is the number of Allocation Requestfields contained in the IE). The Uplink Request IE is optionallycontained in the Connection Request frame to request for creation ormodification of one or more scheduled uplink allocations in beacon ornon-beacon mode with superframes. One or more Allocation Request fieldsare present. Each Allocation Request field is formatted as shown in (B)of FIG. 8. As shown in (B) of FIG. 8, the Allocation Request fieldcontains a Reserved field of one (1) bit.

The Downlink Request IE of the Connection Request frame is formatted asshown in (A) of FIG. 8 in conjunction with (B) of FIG. 8. The DownlinkRequest IE is optionally contained in the Connection Request frame torequest for creation or modification of one or more scheduled downlinkallocations in beacon or non-beacon mode with superframes.

The Bilink Request IE of the Connection Request frame is formatted asshown in (A) of FIG. 8 in conjunction with (B) of FIG. 8. The BilinkRequest IE is optionally contained in the Connection Request frame torequest for creation or modification of one or more scheduled bilinkallocations in beacon or non-beacon mode with superframes.

The Unscheduled Bilink Request IE of the Connection Request frame, whenpresent, is either Type-I Unscheduled Bilink Request IE or Type-IIUnscheduled Bilink Request IE. The Type-I Unscheduled Bilink Request IEis formatted as shown in (A) of FIG. 8 in conjunction with (B) of FIG.8, and is optionally contained in the Connection Request frame torequest for creation or modification of one or more unscheduled bilinkallocations in beacon or non-beacon mode with superframes. The Type-IIUnscheduled Bilink Request IE is formatted as shown in (A) of FIG. 9(where M is the number of Type-II Unscheduled Allocation Request fieldscontained in the IE). The Type-II Unscheduled Bilink Request IE isoptionally contained in the Connection Request frame to request forcreation or modification of one or more unscheduled bilink allocationsin non-beacon mode without superframes. One or more Type-II UnscheduledAllocation Request fields are present in the Type-II Unscheduled BilinkRequest IE. Each Type-II Unscheduled Allocation Request field isformatted as shown in (B) of FIG. 9. As shown in (B) of FIG. 9, theType-II Unscheduled Allocation Request field contains a Reserved fieldof one (1) bit.

According to an embodiment of the present invention, information forindicating the initiative of data communication is added to ConnectionRequest frames. As shown in (B) of FIG. 8 and (B) of FIG. 9, the nodedesignates one bit which is reserved of the Allocation Request fieldcontained in an IE field of the Connection Request frame as aninitiative field. In the case that the node wants to take the initiativeof communication with a hub which is a recipient of the ConnectionRequest frame, the node sets the initiative field to one (1). In thecase of letting the hub take the initiative of the communicationconventionally, the node sets the initiative field to zero (0). Morespecifically, in the case that the node wants to take the initiative ina scheduled uplink allocation, the node sets the one bit which isreserved in the Allocation Request field of the Uplink Request IE to one(1) as shown in (B) of FIG. 8. In the case that the node wants to takethe initiative in a scheduled downlink allocation, the node sets the onebit which is reserved in the Allocation Request field of the DownlinkRequest IE to one (1) as shown in (B) of FIG. 8. In the case that thenode wants to take the initiative in a scheduled bilink allocation, thenode sets the one bit which is reserved in the Allocation Request fieldof the Bilink Request IE to one (1) as shown in (B) of FIG. 8. In thecase that the node wants to take the initiative in a Type-I unscheduledbilink allocation, the node sets the one bit which is reserved in theAllocation Request field of the Unscheduled Bilink Request IE to one (1)as shown in (B) of FIG. 8. In the case that the node wants to take theinitiative in a Type-II unscheduled bilink allocation, the node sets theone bit which is reserved in the Type-II Unscheduled Allocation Requestfield of the Unscheduled Bilink Request IE to one (1) as shown in (B) ofFIG. 9.

A determination on whether to set the initiative field of a ConnectionRequest frame to be transmitted by the node to one (1) is made based onat least one of the kind of the terminal of the node (for example,whether or not the node is a device for frequently transmitting data),the battery remains of the node, the amount of data to be transmitted,and setting of a user (whether or not there is an input from the userfor instructing terminal(s) to operate in low-power mode), for example.

According to the embodiment described above, it is possible to realizedata communication led (or, initiated) by the node by including a fieldindicating a request for the initiative of the data communication inConnection Request frames. In the case that the node transmits aConnection Request frame in which the initiative field is set to one (1)to the hub and the hub receives the Connection Request frame, the hubhands the initiative to the node. In the case that the node takes theinitiative of the communication, it can transmit data frame(s) at propertiming without waiting for receipt of a data frame or a poll from thehub, for example. In other words, even if the node which is a terminaltransmitting a Connection Request frame does not receive thetransmission allowance notice from the hub (in other words, thetransmission allowance notice is not used as a trigger), datacommunication can be started. Thus, there is no necessary for the nodeto be in a receivable state during waiting for the transmissionallowance notice and power consumption of the node can be reduced. Inparticular, for the unscheduled allocation in which an allocation slotcan be shifted in time, the effect of reducing the power consumption ofthe node can be significant.

In a different embodiment of the present invention, the hub transmits aConnection Assignment frame containing an initiative field to the node.The Connection Assignment frame according to the present embodiment isformatted as shown in FIG. 10. Each of a plurality of fields included inthe frame payload of the Connection Assignment frame is defined inSection 5.3.7 of IEEE Std 802.15.6-2012. As shown in FIG. 10, theConnection Assignment frame contains information elements (IEs). Eachinformation element contains an element ID field which is set to thevalue that identifies the information element, a length field, and aninformation field (see (A) of FIG. 11 and (A) of FIG. 12). The lengthfield is set to the length, in octets, of the information field.

The Uplink Assignment IE of the Connection Assignment frame is formattedas shown in (A) of FIG. 11 (where J is the number of AllocationAssignment fields contained in the IE). The Uplink Assignment IE isoptionally contained in the Connection Assignment frame to assign orreassign one or more allocation slot-based scheduled uplink allocationsto the node, which is the recipient of the frame, in beacon ornon-beacon mode with superframes. One or more Allocation Assignmentfields are present. Each Allocation Assignment field is formatted asshown in (B) of FIG. 11. As shown in (B) of FIG. 11, the AllocationAssignment field contains a Reserved field of one (1) bit.

The Downlink Assignment IE of the Connection Assignment frame isformatted as shown in (A) of FIG. 11 in conjunction with (B) of FIG. 11.The Downlink Assignment IE is optionally contained in ConnectionAssignment frames to assign one or more allocation slot-based scheduleddownlink allocations to the node, which is the recipient of the frame,in beacon or non-beacon mode with superframes.

The Bilink Assignment IE of the Connection Assignment frame is formattedas shown in (A) of FIG. 11 in conjunction with (B) of FIG. 11. TheBilink Assignment IE is optionally contained in Connection Assignmentframes to assign one or more allocation slot-based scheduled Bilinkallocations to the node, which is the recipient of the frame, in beaconor non-beacon mode with superframes.

The Unscheduled Bilink Assignment IE of the Connection Assignment frameis either Type-I Unscheduled Bilink Assignment IE or Type-II UnscheduledBilink Assignment IE. The Type-I Unscheduled Bilink Assignment IE isformatted as shown in (A) of FIG. 11 in conjunction with (B) of FIG. 11,and is optionally contained in the Connection Assignment frame to assignor reassign one or more allocation slot-based unscheduled bilinkallocations to the node, which is the recipient of the frame, in beaconor non-beacon mode with superframes. The Type-II Unscheduled BilinkAssignment IE is formatted as shown in (A) of FIG. 12 (where L is thenumber of Type-II Unscheduled Allocation Assignment fields contained inthe IE). The Type-II Unscheduled Bilink Assignment IE is optionallycontained in the Connection Assignment frame to assign or reassign oneor more frame count-based unscheduled bilink allocations to the node,which is the recipient of the frame, in non-beacon mode withoutsuperframes. One or more Type-II Unscheduled Allocation Assignmentfields are present in the Type-II Unscheduled Bilink Assignment IE. EachType-II Unscheduled Allocation Assignment field is formatted as shown in(B) of FIG. 12. As shown in (B) of FIG. 12, the Type-II UnscheduledAllocation Assignment field contains a Reserved field of one (1) bit.

In the present embodiment, the hub designates one bit which is reservedof the Allocation Assignment field of the Uplink Assignment IE, theDownlink Assignment IE, the Bilink Assignment IE, or the UnscheduledBilink Assignment IE of the Connection Assignment frame as an initiativefield. In the case of allowing the node to take the initiative ofcommunication, the hub sets the initiative field to one (1). In the casethat the hub takes the initiative of communication, the hub sets theinitiative field to zero (0). More specifically, in the case that thehub allows the node to take the initiative in a scheduled uplinkallocation, the hub sets the one bit which is reserved in the AllocationAssignment field of the Uplink Assignment IE to one (1) as shown in (B)of FIG. 11. In the case that the hub allows the node to take theinitiative in a scheduled downlink allocation, the hub sets the one bitwhich is reserved in the Allocation Assignment field of the DownlinkAssignment IE to one (1) as shown in (B) of FIG. 11. In the case thatthe hub allows the node to take the initiative in a scheduled bilinkallocation, the hub sets the one bit which is reserved in the AllocationAssignment field of the Bilink Assignment IE to one (1) as shown in (B)of FIG. 11. In the case that the hub allows the node to take theinitiative in a Type-I unscheduled bilink allocation, the hub sets theone bit which is reserved in the Allocation Assignment field of theUnscheduled Bilink Assignment IE to one (1) as shown in (B) of FIG. 11.In the case that the hub allows the node to take the initiative in aType-II unscheduled bilink allocation, the hub sets the one bit which isreserved in the Type-II Unscheduled Allocation Assignment field of theUnscheduled Bilink Assignment IE to one (1) as shown in (B) of FIG. 12.On the other hand, in the case that the hub takes the initiativeconventionally, the hub sets the one bit which is reserved to zero (0).

The hub makes a determination on whether to set the initiative field ofa Connection Assignment frame to one (1) based on at least one of thekind of the terminal of the node (for example, whether or not the nodeis a device for frequently transmitting data), the battery remains ofthe node, the amount of data to be transmitted, and setting of the user(whether or not there is an input from the user for instructingterminal(s) to operate in low-power mode), for example. The nodedetermines whether to operate in normal mode or low-power mode based onthe value of the initiative field of the Connection Assignment framereceived from the hub.

According to another embodiment of the present invention, in the casethat the initiative field of a Connection Request frame received fromthe node is set to one (1) (in other words, the node requests the hub tohand the initiative to the node), the hub responds to the request of thenode by setting the initiative field of a Connection Assignment frame tozero (0) or one (1). In this embodiment, according to the response ofthe hub to the request of the node for the initiative, it is determinedwhether or not the node takes the initiative.

In the embodiments described above, one bit, which is reserved, of theAllocation Request field the IE of the payload of the Connection Requestframe or one bit, which is reserved, of the Allocation Assignment fieldthe IE of the payload of the Connection Assignment frame is used as theinitiative field. However, the present invention is not limited to theseembodiments and any one bit which is reserved may be used as theinitiative field. For example, one bit, which is reserved, of four bitsin the Frame Control of the MAC header of a Connection Request frame ora Connection Assignment frame (see (A) to (C) of FIG. 6) is designatedas an initiative field. In the case of allowing the node to take theinitiative of communication, the initiative field is set to one (1). Inthe case of allowing the node to take the initiative of communication,the initiative field is set to one (1). In the case of letting the hubtake the initiative of the communication, the initiative field is set tozero (0). In another embodiment, the Frame Type field or the FrameSubtype field which is reserved of the MAC header (see Table 1) may beused as the initiative field.

In yet another embodiment, the four (4) bits, which are reserved, of theFrame Control of the MAC header of a Connection Request frame and/or aConnection Assignment frame (see (A) to (C) of FIG. 6) are designated asan initiative field for a scheduled uplink allocation, a scheduleddownlink allocation, a scheduled bilink allocation, and an unscheduledbilink allocation. The kind of field used as the initiative field doesnot constitute the fundamental idea of the invention.

Next, signal flow is explained for communication in unscheduled bilinkallocation(s) in beacon or non-beacon mode with superframes (or, type-Iunscheduled bilink allocation(s)) by way of example. FIG. 13 is a signalflow diagram showing a process of conventional (in other words, innormal mode) Type-I unscheduled bilink communication. FIG. 14 is asignal flow diagram showing a process of Type-I unscheduled bilinkcommunication according to an embodiment of the invention.

Referring to FIG. 13, a node wanting to connect to a hub generates aConnection Request frame and transmits it to the hub. The ConnectionRequest frame contains the Unscheduled Bilink Request IE. If the hubreceives the Connection Request frame, the hub transmits an Ack framewhich is a receipt acknowledgement message to the node. Then, in thecase that there is a reason for rejecting the connection request of thenode, the hub generates a Connection Assignment frame in which theConnection Status field of the Mode/Status field is set to one of one(1) to ten (10) according to the reason and transmits it to the node.Thus, the connection process ends. In the case that there is no reasonfor rejecting the connection request of the node, the hub generates aConnection Assignment frame in which the Connection Status field of theMode/Status field is set to zero (0) and transmits it to the node. Ifthe node receives the Connection Assignment frame in which theConnection Status field of the Mode/Status field is set to zero (0), thenode transmits an Ack frame to the hub and stands by in the receivablestate. As shown in FIG. 13, if the node receives a poll (or a dataframe) from the hub, the node transmits a data frame to the hub.

Since the hub takes the initiative in the conventional bilinkcommunication as described above, the node should maintain the receiptstandby state until the poll is received from the hub in a givenallocation slot. In particular, for the unscheduled allocation in whichan allocation slot can be shifted in time, the receipt standby time maybe too long. This receipt standby time results in increase of powerconsumption of the node.

Referring to FIG. 14, a Connection Request frame which a node transmitsto a hub contains the Unscheduled Bilink Request IE and the IE containsthe initiative field according to the present embodiment (see (A) and(B) of FIG. 8). The hub processes the Connection Request frame and, inthe case that the initiative field is set to one (1), the hub determineswhether to allow the node to take the initiative. In the case ofallowing the node to take the initiative, the hub generates a ConnectionAssignment frame in which the initiative field contained in theUnscheduled Bilink Assignment IE is set to one (1) (see (A) and (B) ofFIG. 11). On the other hand, in the case of not allowing the node totake the initiative, the hub generates a Connection Assignment frame inwhich the initiative field contained in the Unscheduled BilinkAssignment IE is set to zero (0). As described above, the presentinvention is not limited to the above embodiment in which the ConnectionRequest frame contains the initiative field in the Unscheduled BilinkRequest IE and the initiative field may be contained in a different areaof the Connection Request frame (for example, a reserved field of theMAC header of the frame). Similarly, the present invention is notlimited to the embodiment in which the Connection Assignment framecontains the initiative field in the Unscheduled Bilink Assignment IEand the initiative field may be contained in a different area of theConnection Assignment frame (for example, a reserved field of the MACheader of the frame).

The node operates in low-power mode in the case that the initiativefield of the Connection Assignment frame received from the hub is set toone (1). Thus, the node initiates data communication at proper timing ina given allocation slot (in other words, the node initiates transmissionof data frame(s)). Accordingly, the node does not need to maintain thereceipt standby state until the transmission allowance notice isreceived from the hub as it does conventionally. Therefore, it ispossible to reduce power consumption of the node. The proper timing canbe determined, for example, according to the amount of data to betransmitted to the hub by the node.

Further, according to the embodiment shown in FIG. 14, in the case thatthe initiative field contained in the Unscheduled Bilink Request IE ofthe Connection Request frame is set to one (1) and the initiative fieldcontained in the Unscheduled Bilink Request IE of the ConnectionAssignment frame is set to one (1), the node takes the initiative.However, the present invention is not limited thereto. In otherembodiments, a hub allows a node to take the initiative of communicationonly by receiving a Connection Request frame in which the initiativefield is set to one (1) from the node.

FIGS. 15 and 16 are flow charts showing operations of algorithmsperformed by a node and a hub, respectively, for communication inunscheduled bilink allocation(s) in beacon or non-beacon mode withsuperframes (or, type-I unscheduled bilink allocation(s)), by way ofexample, according to an embodiment of the invention. In the following,details of FIG. 15 will be described referring to FIG. 2.

In the case that the wireless communicator 310 of the node 300 receivesa beacon frame transmitted from the hub 200 (Step S1502), the processor320 of the node 300 processes the beacon frame. The processor 320determines whether to take the initiative of bilink communication withthe hub 200 (Step S1504). This determination is made based on at leastone of the kind of the terminal of the node 300 (for example, whether ornot the node is a device for frequently transmitting data), the batteryremains of the node 300, the amount of data to be transmitted, andsetting of the user (whether or not there is an input from the user forinstructing terminal(s) to operate in low-power mode), for example. Inthe case that the node 300 determines to take the initiative of thebilink communication (Step S1504: YES), it generates a ConnectionRequest frame in which the initiative field is set to one (1) (StepS1506). The wireless communicator 310 transmits the Connection Requestframe to the hub 200 (Step S1508).

Then, in the case that the node 300 receives a Connection Assignmentframe from the hub 200 for accepting the connection request (StepS1510), the node 300 operates low-power mode. More specifically, thenode initiates data communication at proper timing without waiting forreceipt of a poll or a data frame from the hub 200 in a given allocationslot (Step S1512). In other words, the node transmits a data frame tothe hub at proper timing without waiting for receipt of a poll or a dataframe from the hub. The proper timing can be determined, for example,according to the amount of data to be transmitted by the node. Then, oneor more frame transaction(s) are performed between the node and the hub(Step S1514). If a given allocation slot ends, the node and the hub stopthe frame transactions.

In the case that the node 300 does not take the initiative of the bilinkcommunication (Step S1504: NO), the node 300 sets the initiative fieldof the Connection Request frame to zero (0) (Step S1516) and operates innormal mode, in other words, according to the conventional process shownin FIG. 13 (Step S1518).

In the following, operations of the hub according to the presentembodiment will be described with reference to FIG. 16 in conjunctionwith FIG. 2.

In the case that the wireless communicator 210 of the hub 200 receives aConnection Request frame transmitted by the node 300 (Step S1602), theprocessor 220 of the hub 200 processes the Connection Request frame. Theprocessor 220 determines whether or not the initiative field containedin the Connection Request frame is set to one (1) (Step S1604). In thecase that the initiative field contained in the Connection Request frameis set to one (1) (Step S1604: YES), the hub 200 operates in low-powermode. In other words, the hub allows the node to take the initiative ofbilink communication between them. Then, the hub 200 transmits a

Connection Assignment frame to the node 300 (Step S1606). In this case,the hub 200 neither transmits a poll to the node 300 nor initiates datacommunication. In the case that the wireless communicator 210 receives adata frame from the node 300 (Step S1608), one or more frametransaction(s) are performed between the node and the hub (Step S1610).If a given allocation slot ends, the node and the hub stop the frametransactions.

On the other hand, in the case that the initiative field contained inthe Connection Request frame is not set to one (1) (Step S1604: NO), thehub operates in normal mode, in other words, according to theconventional process shown in FIG. 13 (Step S1612).

FIGS. 17 and 18 are flow charts showing operations of algorithmsperformed by a node and a hub, respectively, for communication inunscheduled bilink allocation(s) in beacon or non-beacon mode withsuperframes (or, type-I unscheduled bilink allocation(s)), by way ofexample, according to another embodiment of the invention. First,details of FIG. 17 will be described referring to FIG. 2.

In the case that the wireless communicator 310 of the node 300 receivesa beacon frame transmitted from the hub 200 (Step S1702), the processor320 of the node 300 processes the beacon frame. The processor 320determines whether to take the initiative of bilink communication withthe hub 200 (Step S1704). This determination is made based on at leastone of the kind of the terminal of the node 300 (for example, whether ornot the node is a device for frequently transmitting data), the batteryremains of the node 300, the amount of data to be transmitted, andsetting of the user (whether or not there is an input from the user forinstructing terminal(s) to operate in low-power mode), for example. Inthe case that the node 300 determines to take the initiative of thebilink communication (Step S1704: YES), it generates a ConnectionRequest frame in which the initiative field is set to one (1) (StepS1706). The wireless communicator 310 transmits the Connection Requestframe to the hub 200 (Step S1708).

Then, in the case that the node 300 receives a Connection Assignmentframe from the hub 200 for assigning one or more slots for the bilinkcommunication (Step S1710), the node 300 determines whether or not theinitiative field contained in the Connection Assignment frame is set toone (1) (Step S1712). In the case that the initiative field contained inthe Connection Assignment frame is set to one (1) (Step S1712: YES), inother words, the hub 200 allows the node 300 to take the initiative, thenode 300 operates in low-power mode. More specifically, the node 300initiates data communication at proper timing without waiting forreceipt of a poll or a data frame from the hub 200 in a given allocationslot (Step S1714). The proper timing can be determined, for example,according to the amount of data to be transmitted by the node. Then, oneor more frame transaction(s) are performed between the node and the hub(Step S1716). If a given allocation slot ends, the node and the hub stopthe frame transactions.

In the case that the node 300 does not take the initiative of the bilinkcommunication (Step S1704: NO), the node 300 sets the initiative fieldof the Connection Request frame to zero (0) (Step S1718) and operates innormal mode, in other words, according to the conventional process shownin FIG. 13 (Step S1720).

In the case that the initiative field contained in the ConnectionAssignment frame is not set to one (1) (Step S1712: NO), in other words,the hub 200 does not allow the node 300 to take the initiative, the node300 waits for receipt of a poll or a data frame from the hub 200 (StepS1722). In the case that a poll or a data frame is received from the hub200 within a predetermined time period (Step S1722: YES), one or moreframe transaction(s) are performed between the node and the hub (StepS1716). If a given allocation slot ends, the node and the hub stop theframe transactions. On the other hand, in the case that neither a pollnor a data frame is received from the hub 200 within the predeterminedtime period (Step S1722: NO), the present allocation interval ends inthe state where the node 300 transmits no data frame. The predeterminedtime period can be determined according to the length of the allocationslot(s), for example.

Then, details of FIG. 18 will be described referring to FIG. 2. In thecase that the wireless communicator 210 of the hub 200 receives aConnection Request frame transmitted by the node 300 (Step S1802), theprocessor 220 of the hub 200 processes the Connection Request frame. Theprocessor 220 determines whether or not the initiative field containedin the Connection Request frame is set to one (1) (Step S1804). In thecase that the initiative field contained in the Connection Request frameis set to one (1) (Step S1804: YES), in other words, the node 300requests the hub 200 to allow the node 300 to take the initiative of thebilink communication, the hub 200 determines whether to allow the node300 to take the initiative (Step S1806). This determination is madebased on at least one of the kind of the terminal of the node 300 (forexample, whether or not the node is a device for frequently transmittingdata), the battery remains of the node 300, the amount of data to betransmitted, and setting of the user (whether or not there is an inputfrom the user for instructing terminal(s) to operate in low-power mode),for example.

In the case that the hub 200 allows the node 300 to take the initiativeof the bilink communication (Step S1806: YES), the processor 220 of thehub 200 generates a Connection Assignment frame in which the initiativefield is set to one (1) (Step S1808). The wireless communicator 210transmits the Connection Assignment frame to the node 300 (Step S1810)and the processor 220 operates in low-power mode. In this case, the hub200 neither transmits a poll to the node 300 nor initiates datacommunication. In the case that the wireless communicator 210 receives adata frame from the node 300 (Step S1812), one or more frametransaction(s) are performed between the node and the hub (Step S1814).If a given allocation slot ends, the node and the hub stop the frametransactions.

On the other hands, in the case that the initiative field contained inthe Connection Request frame is not set to one (1) (Step S1804: NO), thehub 200 operates in normal mode, in other words, according to theconventional process shown in FIG. 13 (Step S1816). Further, in the casethat the hub 200 does not allow the node 300 to take the initiative(Step S1806: NO), the initiative field of the Connection Assignmentframe is set to zero (0). The hub 200 operates in normal mode, in otherwords, according to the conventional process shown in FIG. 13 (StepS1816).

FIGS. 19 and 20 are flow charts showing operations of algorithmsperformed by a node and a hub, respectively, for communication inunscheduled bilink allocation(s) in beacon or non-beacon mode withsuperframes (or, type-I unscheduled bilink allocation(s)), by way ofexample, according to yet another embodiment of the invention. First,details of FIG. 17 will be described referring to FIG. 2. The presentembodiment is different from those of FIGS. 15 to 18 in that informationshowing the initiative of communication is contained only in ConnectionAssignment frames. First, details of FIG. 19 will be described referringto FIG. 2.

In the case that the wireless communicator 310 of the node 300 receivesa beacon frame transmitted from the hub 200 (Step S1902), the processor320 of the node 300 processes the beacon frame. The node 300 generates aConnection Request frame and transmits it to the hub 200 (Step S1904).Then, in the case of receiving a Connection Assignment frame from thehub 200 (Step S1906), the node 300 determines whether or not theinitiative field contained in the Connection Assignment frame is set toone (1) (Step S1908). In the case that the initiative field contained inthe Connection Assignment frame is set to one (1) (Step S1908: YES), inother words, the node 300 is allowed to take the initiative of thecommunication, the node 300 operates in low-power mode. Morespecifically, the node 300 initiates data communication at proper timingwithout waiting for receipt of a poll or a data frame from the hub 200in a given allocation slot (Step S1910). The proper timing can bedetermined, for example, according to the amount of data to betransmitted by the node. Then, one or more frame transaction(s) areperformed between the node and the hub (Step S1912). If a givenallocation slot ends, the node and the hub stop the frame transactions.

On the other hand, in the case that the initiative field contained inthe Connection Assignment frame is not set to one (1) (Step S1908: NO),the node 300 waits for receipt of a poll or a data frame from the hub200 (Step S1914). In the case that a poll or a data frame is receivedfrom the hub 200 within a predetermined time period (Step S1914: YES),one or more frame transaction(s) are performed between the node and thehub (Step S1912). If a given allocation slot ends, the node and the hubstop the frame transactions. On the other hand, in the case that neithera poll nor a data frame is received from the hub 200 within thepredetermined time period (Step S1914: NO), the present allocationinterval ends in the state where the node 300 transmits no data frame.The predetermined time period can be determined according to the lengthof the allocation slot(s), for example.

Then, details of FIG. 20 will be described referring to FIG. 2. In thecase that the wireless communicator 210 of the hub 200 receives aConnection Request frame transmitted by the node 300 (Step S2002), theprocessor 220 of the hub 200 processes the Connection Request frame. Theprocessor 220 determines whether to allow the node to take theinitiative (in other words, whether to operate in low-power mode) (StepS2004). This determination is made based on at least one of the kind ofthe terminal of the node 300 (for example, whether or not the node is adevice for frequently transmitting data), the battery remains of thenode 300, the amount of data to be transmitted, and setting of the user(whether or not there is an input from the user for instructingterminal(s) to operate in low-power mode), for example. In the case ofallowing the node 300 to take the initiative of the bilink communication(Step S2004: YES), the hub 200 generates a Connection Assignment framein which the initiative field is set to one (1) (Step S2006). Thewireless communicator 210 transmits the Connection Assignment frame tothe node 300 (Step S2008) and the processor 220 operates in low-powermode. In this case, the hub 200 neither transmits a poll to the node 300nor initiates data communication. In the case that the wirelesscommunicator 210 receives a data frame from the node 300 (Step S2010),one or more frame transaction(s) are performed between the node and thehub (Step S2012). If a given allocation slot ends, the node and the hubstop the frame transactions.

On the other hand, in the case that the hub 200 does not allow the node300 to take the initiative, in other words, the hub does not operate inlow-power mode (Step S2004: NO), the hub 200 operates in normal mode, inother words, according to the conventional process shown in FIG. 13(Step S2014).

Second Embodiment

FIG. 21 shows an embodiment of a device capable of functioning as thehub or the node in the BAN. An exterior view of the device is shown in(A) of FIG. 21 and a block diagram showing a hardware configuration ofthe device is shown in (B) of FIG. 21. In the present embodiment, thedevice is an electronic timepiece. As shown in (B) of FIG. 21, anelectronic timepiece 2100 includes a communication module 2110, and thecommunication module 2110 includes an antenna 2112, a wirelesscommunicator 2114, and a processor 2116. The processor 2116 processesmessages exchanged via the antenna 2112 and the wireless communicator2114 and/or via a wireline connected to the internet or a different bodyarea network (not shown in the drawing). The processor 2116 may includesoftware, firmware, or hardware. Since the configurations and functionsof the antenna 2112, the wireless communicator 2114, and the processor2116 are the same as those of the antenna 212 or 312, the wirelesscommunicator 210 or 310, and the processor 220 or 320 as described withrespect to FIG. 2, more detailed explanation on them is omitted.Further, the communication module 2110 may include a memory (not shownin the drawing) for storing frame data exchanged with other device(s),data such as the frame structure information, the medium access controlinformation and the power management information, computer programinstructions, software and/or firmware executed by the processor 2116,or the like.

A central processor 2120 includes a processing unit such as a CPU(Central Processing Unit) and controls operations of the timepiece 2100.For example, the central processor 2120 executes various processesaccording to programs recorded on a ROM 2160. The configurations andfunctions of the processor 220 or 320 described with respect to FIG. 2can be realized by the central processor 2120 or cooperation of thecentral processor 2120 and the processor 2116.

An input unit 2130 includes a plurality of buttons (here, the buttonsmay be realized by hardware and/or software) having a function ofinputting various information and instructions to the timepiece 2100. Ifa user manipulates the buttons, the input unit 2130 outputs instructionscorresponding to the manipulated buttons to the central processor 2120.The central processor 2120 controls each unit to execute a predeterminedoperation according to the instructions input from the input unit 2130.

A display 2140 displays various kinds of information such as time or amessage received from the outside according to an instruction from thecentral processor 2120.

A counter 2150 generates time signals from signals generated by a systemclock or an oscillator and outputs current time.

The ROM 2160 is used to store control programs executed by the centralprocessor 2120 and the like. Further, the ROM 2160 may be used to storecomputer program instructions, software and/or firmware executed by theprocessor 2116.

A RAM 2170 provides a work area when the central processor 2120 executesvarious processes and is used to store data processed by each unit ofthe timepiece 2100. The RAM 2170 may be used to store data such as theframe structure information, the medium access control information, andthe power management information, as well as the frame data transmittedor received.

The timepiece 2100 can be connected to other device. The other deviceincludes a sensor used to monitor data from the body such as bodytemperature, respiration, heart rate, or blood sugar, or a device forproviding a function of controlling a pace maker, a respirator, aninsulin pump, or the like, for example.

The present invention has been described with respect to specificembodiments in which it has been applied to the BAN but its applicationfield is not limited to the BAN. For example, the invention can beapplied to different wireless communication technologies such asBluetooth®, Wi-Fi®, and Wi-Fi Direct®.

The processes described above can be executed by hardware or software.In the case that a specific process is executed by software, a programconfiguring the software is installed in the communication deviceserving as the hub or the node from a network or a storage medium. Arecording medium for recording such a program thereon includes aremovable media which is distributed separately from the device's mainbody to provide it to users or a recording medium or the like which isprovided to users in a state of being incorporated in the device's mainbody in advance.

Many modifications and other embodiments of the invention will come tomind to one skilled in the art to which this invention pertains havingthe benefit of the teachings presented in the foregoing descriptions,and the associated drawings. Therefore, it is to be understood that theinvention is not to be limited to the specific embodiments disclosed.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation. Thesemodifications and embodiments fall within the scope and the spirit ofthe invention described in this specification and within the scope ofthe invention as defined in the appended claims and equivalents thereof.

What is claimed is:
 1. A device for communication according to aspecific communication protocol comprising: a processor for generating aconnection request frame for requesting a connection to other devicebased on the communication protocol, the connection request frameincluding a predetermined field, wherein the processor initiates datacommunication at predetermined timing in a time interval given forcommunication with the other device in the case of setting thepredetermined field of the connection request frame to a predeterminedvalue and receiving a connection assignment frame for accepting theconnection request from the other device.
 2. The device of claim 1,wherein the processor determines a value of the predetermined fieldbased on at least one of the kind of the device, battery remains of thedevice, the amount of data to transmit to the other device, and settingof a user.
 3. The device of claim 1, wherein the predetermined timing isdetermined according to the amount of data to transmit to the otherdevice.
 4. The device of claim 1, wherein the processor waits to receivea poll from the other device without transmitting any data frame to theother device in the case of setting the predetermined field of theconnection request field to a value different from the predeterminedvalue.
 5. The device of claim 1, wherein the processor waits to receivea data frame from the other device without transmitting any data frameto the other device in the case of setting the predetermined field ofthe connection request field to a value different from the predeterminedvalue.
 6. The device of claim 1, wherein the predetermined field isincluded in an allocation request field of an information element of theconnection request frame.
 7. The device of claim 1, wherein the deviceperforms unscheduled bilink communication with the other device.
 8. Thedevice of claim 1, wherein the processor determines whether or not apredetermined field of the connection assignment frame received from theother device is set to a predetermined value, in the case that thepredetermined field of the connection assignment frame is set to thepredetermined value, the processor initiates data communication at thepredetermined timing, and in the case that the predetermined field ofthe connection assignment frame is not set to the predetermined value,the processor does not transmit any data frame to the other device untila poll is received from the other device.
 9. The device of claim 1,wherein the processor determines whether or not a predetermined field ofthe connection assignment frame received from the other device is set toa predetermined value, in the case that the predetermined field of theconnection assignment frame is set to the predetermined value, theprocessor initiates data communication at the predetermined timing, andin the case that the predetermined field of the connection assignmentframe is not set to the predetermined value, the processor does nottransmit any data frame to the other device until a data frame isreceived from the other device.
 10. A timepiece comprising: a device ofclaim 1; and a counter configured to count current time.
 11. A devicefor communication according to a specific communication protocolcomprising: a processor for generating a connection assignment frame foraccepting a connection request of other device based on thecommunication protocol, the connection assignment frame including apredetermined field, wherein the processor does not transmit any dataframe until the other device initiates data communication in the case ofsetting the predetermined field of the connection assignment frame to apredetermined value.
 12. The device of claim 11, wherein the processordetermines whether to set the predetermined field of the connectionassignment frame to the predetermined value in the case of receiving aconnection request frame in which a predetermined field is set to apredetermined value from the other device.
 13. A timepiece comprising: adevice of claim 11; and a counter configured to count current time. 14.A device for communication according to a specific communicationprotocol comprising: a processor for determining whether or not apredetermined field included in a connection request frame forrequesting a connection to the device received from other device is setto a predetermined value, wherein the processor does not transmit anydata frame to the other device until the other device initiates datacommunication in the case that the predetermined field of the connectionrequest frame is set to the predetermined value.
 15. A timepiececomprising: a device of claim 14; and a counter configured to countcurrent time.
 16. A communication method performed by a device capableof communication according to a specific communication protocolcomprising: generating a connection request frame for requesting aconnection to other device in which a predetermined field is set to apredetermined value, based on the communication protocol; and initiatingdata communication at predetermined timing in a time interval given forcommunication with the other device in the case of receiving aconnection assignment frame for accepting the connection request fromthe other device.
 17. A communication method performed by a devicecapable of communication according to a specific communication protocolcomprising: generating a connection assignment frame for accepting aconnection request of other device in which a predetermined field is setto a predetermined value, based on the communication protocol; andwaiting until the other device initiates data communication withouttransmitting any data frame to the other device.
 18. A communicationmethod performed by a system comprising a first device and a seconddevice for communication according to a specific communication protocolcomprising: at the first device, generating a connection request framefor requesting a connection to the second device in which apredetermined field is set to a predetermined value, based on thecommunication protocol; at the first device, transmitting the connectionrequest frame to the second device; at the second device, receiving theconnection request frame to the first device; at the second device,generating a connection assignment frame for accepting the connectionrequest of the first device based on the communication protocol; at thesecond device, transmitting the connection assignment frame to the firstdevice; at the first device, receiving the connection assignment framefrom the second device; and at the first device, initiating datacommunication at predetermined timing in a time interval given forcommunication with the other device.
 19. A non-transitorycomputer-readable recording medium for recording a computer programcontrolling a device capable of communication according to a specificcommunication protocol, the program causing the device to perform stepsof: generating a connection request frame for requesting a connection toother device in which a predetermined field is set to a predeterminedvalue, based on the communication protocol; and initiating datacommunication at predetermined timing in a time interval given forcommunication with the other device in the case of receiving aconnection assignment frame for accepting the connection request fromthe other device.
 20. A non-transitory computer-readable recordingmedium for recording a computer program controlling a device capable ofcommunication according to a specific communication protocol, theprogram causing the device to perform steps of: generating a connectionassignment frame for accepting a connection request of other device inwhich a predetermined field is set to a predetermined value, based onthe communication protocol; and waiting until the other device initiatesdata communication without transmitting any data frame to the otherdevice.